-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Load Microsoft.DotNet.MSBuildSdkResolver into default load context (MSBuild.exe only) #9439
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
7098a6f to
a31fbff
Compare
|
Should this go to 17.9? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this go to 17.9?
I believe so. Because the SDK is now attempting to NGEN the resolver against MSBuild.exe but the app.config is missing the requisite redirects, PerfDDRITs have flagged a regression in "invalid assembly count". Merging this into 17.9 would prevent that regression (however insignificant) to be shipped publicly.
…eline (#37381) As pointed out in dotnet/msbuild#9439 (comment), we have to be careful when changing the set of dependencies of the SDK resolver assembly as it may impact binding redirects in MSBuild's app.config. This PR adds a simple post-build step which compares the dependencies of the just-built assembly with a baseline. Co-authored-by: Rainer Sigwald <[email protected]>
aa68c3a to
e3b2480
Compare
|
I have retargeted the PR to 17.9. |
e3b2480 to
90997de
Compare
…ntext (MSBuild.exe only) (dotnet#9439)" This reverts commit 6257b8e.
…ntext (MSBuild.exe only) (dotnet#9439)" This reverts commit 6257b8e.
…ntext" (#9857) (#9861) * Revert "Load Microsoft.DotNet.MSBuildSdkResolver into default load context (MSBuild.exe only) (#9439)" This reverts commit 6257b8e. * Bump version Co-authored-by: Ladi Prosek <[email protected]>
…ontext" (#10603) ### Context Now that dotnet/sdk#39573 has made it into VS, we can finally enable loading `Microsoft.DotNet.MSBuildSdkResolver` by assembly name, as opposed to file path, which makes it possible to use its NGEN image. ### Changes Made Re-did #9439 which had to be reverted because of the problematic dependency on `Newtonsoft.Json`. The .NET SDK resolver does not depend on `Newtonsoft.Json` anymore. All the other pieces are already in place: - `Microsoft.DotNet.MSBuildSdkResolver` is NGENed, both for MSBuild.exe and for devenv.exe. - `devenv.exe.config` contains binding redirects analogous to what's added in this PR. ### Testing Experimentally inserted into VS and verified that `Microsoft.DotNet.MSBuildSdkResolver` is no longer JITted, saving ~50-100 ms of MSBuild.exe startup time.
Fixes #9303
Context
After a new version of
VS.Redist.Common.Net.Core.SDK.MSBuildExtensionsis inserted into VS, a native image forMicrosoft.DotNet.MSBuildSdkResolverwill be generated, both for devenv.exe and MSBuild.exe (see dotnet/installer#17732).We currently load SDK resolvers using
Assembly.LoadFromon .NET Framework, which disqualifies it from using native images even if they existed. This PR makes us use the native image.Changes Made
Added a code path to use
Assembly.Loadto load resolver assemblies. The call is made such that if the assembly cannot be found by simple name, it falls back to loading by path into the load-from context, just like today. The new code path is enabled only forMicrosoft.DotNet.MSBuildSdkResolverunder a change-wave check.Testing
Experimental insertions.
Notes
Using
qualifyAssemblyin the app config has the advantage of keeping everything field-configurable, i.e. in the unlikely case that a custom build environment will ship with a different version of the resolver, it will be possible to compensate for that by tweaking the config file. The disadvantage is that the samequalifyAssemblywill need to be added to devenv.exe.config because .pkgdef doesn't support this kind of entry, to my best knowledge. It should be a one-time change, though, because we have frozen the version ofMicrosoft.DotNet.MSBuildSdkResolverto 8.0.100.0.